The present specification generally relates to ultra-low latency services which require ultra-low latency connection. Vehicle-to-X (V2X) communication is such ultra-low latency service, wherein V2X services include, for example, vehicle-to-vehicle and vehicle-to-pedestrians services.
While in the explanations below, reference is made to V2X as an example of ultra-low latency services to which the present application is applicable, the field of the present invention is not limited to V2X but instead also applicable to further ultra-low latency services such as, for example, gaming applications and “Broadband Access in a Crowd”.
As mentioned above, V2X related services require ultra-low latency connection. For instance, according to 3rd Generation Partnership Project (3GPP) TR 22.885 “Study on LTE Support for V2X services”, chapter 5.12 (“Pre-crash Warning”), a delay of less than 20 ms is required. Furthermore according to the Internet Engineering Task Force (IETF) draft “Deterministic Networking Use Cases Version 03” chapter 8.5 (“Vehicle to Vehicle”), the requirement is even given to be 5 ms for such services.
Accordingly, it is currently required for the V2X server application to run on the mobile edge computing (MEC) server, e.g., on the evolved NodeB (eNodeB, eNB) or distributed cloud/data centers (from a latency perspective still very close to the eNB site). Consequently the V2X server application either is to be deployed on every eNB, which is costly and also is scattered across the numerous eNB sites, or in clouds which are in terms of latency close-by. Anyhow, all the user plane traffic of the corresponding application is to be forwarded to the MEC (formerly known as radio applications cloud server (RACS)) platform and to the V2X application running on top of it.
Such approach, however, consumes forwarding capacity, which more and more will become a scarce resource in the future due to steadily increasing data amount. In the mentioned V2X scenario, according to such approach, the messages to be sent for instance from one vehicle to another vehicle are to be firstly sent up to the V2X server application for consideration, evaluation and decision as to where the particular message is to be sent.
Only after this decision (of the V2X server application hosted on the MEC server) the corresponding message is forwarded to the vehicle addressed.
V2X capabilities may include “Warning to Pedestrian against Pedestrian Collision” (see e.g. 3GPP TR 22.885 “Study on LTE Support for V2X services”). In order to be able to avoid any collisions, special warning messages are to be exchange between the parties.
A corresponding exemplary scenario is depicted in FIG. 9, in which a vehicle 91 and a pedestrian 92, while not in the respective visible ranges, are heading (91a, 92a) for a collision. In order to enable the above warning against pedestrian collision, a message is to be transmitted from the vehicle to the pedestrian, as indicated by the curved arrow (93).
V2X capabilities may further include “Pre-crash Sensing Warning” between vehicles. This pre-crash sensing warning also requires that possibly intersecting cars are considered. In such case, at least two cars may possibly collide. Consequently, the corresponding warning messages need to be exchanged between (at least) these two cars. However, the two cars might be out of direct sight. Furthermore, these two cars might be attached to two different eNBs or radio access networks (e.g. 5G radio access networks (RAN)).
This means that an implementation in which application servers that only have “local” knowledge (i.e. knowledge limited to the “own” eNB) may not work in any case (namely, may not work at least in case the two cars are attached to two different eNBs). Further, in this context it should be considered that there may be a requirement according to which roaming is to be supported (see e.g. 3GPP TR 22.885 “Study on LTE Support for V2X services”, chapter 5.21.5), which may be problematic in case of an implementation of the V2X server application on the eNB.
This further means that an implementation in which V2X communication is effected by means of a direct car to car communication may not work in any case (namely, may not reliably work under certain circumstances like weather conditions (e.g. fog) and topology blocking (e.g. buildings and shadowing by the buildings). Further, direct communication between cars and road units would require massive deployment of roadside equipment, which would be expensive.
As already mentioned, while the above has been described in the context of V2X requirements, a disposal of a substantial application regarding services, in particular ultra-low latency services, on the MEC site may raise similar problems as well. In particular, any MEC application may not be interested in all the traffic carried on e.g. the S1 interface.
Regarding vehicular communication like vehicle-to-vehicle (V2V) communication, it is noted that the corresponding server application may be hosted on the MEC server on the eNB in order to fulfil the ultra-low latency requirements, as mentioned above. Here, of course, at least challenges with respect to user equipment (UE) handover and relocation of respective server application may arise. Further, with such approach, the processing cost per bit can be expected to be high without centralized data center servers.
As long the ultralow latency requirements of V2X can be fulfilled, the MEC framework (and thus the server application) may be placed on local/distributed cloud center sites as well which are close enough to the eNB sites from the latency point of view (ultralow latency requirements).
However, according to ETSI TR 102 962 V1.1.1, V2X messages are to be sent to the cooperative intelligent transport system (C-ITS) server 101 (e.g. FIG. 10).
That is, all V2X messages are sent directly from the vehicle application to the V2X server application on the server (C-ITS) 101, which in return need to redistribute the communication to the vehicle side's application on the cars (102, 103) which are participating in this service.
Consequently, e.g. in Long Term Evolution (LTE) and/or 5G, there are two options for transmission of the V2X related messages.
Namely, on the one hand, the communication messages are all sent via the packet data network gateway (PGW, PDN-GW) or the corresponding gateway in the 5G network (or even the successor network) to the V2X server application (on the server in the data center) and back from the V2X server application (on the server in the data center) via the PGW to the V2X application in the car.
Further, on the other hand, the communication messages are sent to the MEC/RACS (deployed at the eNB) hosting such V2X server application and back to the V2X application in the car.
In this regard, it is noted that e.g. according to 3GPP TS23.203 (“Policy and charging control architecture”), the PGW or the corresponding gateway of the 5G architecture may embody the policy and charging enforcement function (PCEF), and an application function (AF) may be allowed to instruct the PCEF, as illustrated in FIG. 11.
FIG. 12 depicts an example with applications like the V2X server application hosted on the eNB due to the ultra-low latency requirements. The V2X server application receives the whole traffic (from radio side or core). Accordingly, the application/service payload (i.e. communication messages) is completely sent up to the e.g. V2X application and is forwarded back again towards the final destination.
With respect to the communication messages mentioned above, it is noted that according to ETSI TS 102 637-1 “Intelligent Transport Systems (ITS), Vehicular Communications, Basic Set of Applications, Part 1: Functional Requirements” (chapter 6.1.4.3 UC003 “Intersection collision warning”), collaborative/cooperative awareness messages (CAM) and possibly decentralized environmental notification messages (DENM) are sent to alert other vehicles about possible risks.
In ETSI EN 302 636-5-1 (Intelligent Transport Systems (ITS), Vehicular Communications, GeoNetworking, Part 5: Transport Protocols, Sub-part 1: basic transport protocol (BTP)), the V2X stage 3 transport protocol carrying the CAM and DENM messages is specified.
According thereto, within the BTP, the CAM and DENM message are distinguished by the respective ports as derivable from the following table.
Details regarding these messages are derivable from the related standard mentioned as well in the table below.
ITS facilities layerRelated standard of ITSBTP portentityfacilities layer entity2001CAMEN 302 637-2 [i.3]2002DENMEN 302 637-3 [i.4]2003TOPONA2004SPATNA2005SAMTS 102 890-2 [i.5]
As further prior art, proximity service (ProSe) is known, which is a device-to-device (D2D) communication technology. The discovery and connectivity procedure of ProSe is depicted in FIG. 13.
Applying principles of ProSe would entail that it may take about 10 s until the connectivity between two devices which are 150 m apart from each other is established. As such this D2D approach is not feasible and sufficient for the use case of intersection collision warning in the context of V2X. If, for example, both cars would move at a speed of 50 km/h on orthogonal streets, they may collide even before the connectivity between them would have been established. It is to be noted that in addition it might be questionable whether in urban areas connectivity within 150 m may be possible at all (e.g. due to shadowing).
Consequently, a solution is needed which overcomes the drawbacks and deficiencies of the known art discussed above.
In particular, the problem arises that known techniques do not provide ultra-low latency connection, is costly and requires scattered facilities, requires high processing power, and causes high traffic load.
Hence, there is a need to provide for efficient and dynamic support of mobile low latency services.